A number of challenges exist in providing reliable communications among and between ground stations and satellites, particularly in communication systems that employ small satellites having limited power. High bit-error-rates (or even complete communication failure) can result when scarce resources are not properly utilized and/or when sources of interference are not properly managed. For example, limited battery and solar power on a satellite can limit the available radio frequency (RF) power for radio transmission of data, which can result in a low signal-to-noise ratio and a corresponding high bit-error-rate. Furthermore, the communications link between ground stations and orbiting satellites have limited time-windows that can vary in noise/reliability as a function of interference sources, satellite azimuth and elevation angles with respect to the ground station, etc. In addition, the process of attempting to receive data while simultaneously transmitting can overwhelm the receiver. Thus, a number of factors associated with satellite communications can cause data to be delayed, received out of order, received with a high error rate, and/or lost.
Certain networking communication protocols, such as the OSI five layer networking stack, have been developed and successfully utilized for terrestrial data communications, but such protocols do not always work well for small satellite communications. Many satellite communication systems instead use a modified networking stack known as Cubesat Space Protocol (CSP), comprehensively documented, and published by GomSpace. The CSP protocol follows the TCP/IP model and includes transport and routing protocols. Unfortunately, certain layers available in CSP may not be ideal for certain satellite communication schemes.
TCP/IP protocols used in terrestrial networking guarantees/requires delivery and order of delivery. CSP employs a Reliable Datagram Protocol (RDP), which is a simplified version of TCP based on RFC 1151. Like TCP, RDP requires maintenance of synchronization of sequence numbers between the satellite and the ground station, resulting in frequent delays and protocol errors due to lost packets and protocol complexity. In a half-duplex, high-data-loss environment, such as ground to satellite communications, this method may be completely unworkable. For instance, not all packets may be received in a high loss environment, which would result in the transmitting node continuing to transmit packets long after the pass has completed, resulting in extremely dire consequences, such as the satellite completely discharging its batteries in an attempt to continue transmitting. In addition, a handshake needs to be initiated, typically from the ground station side. Constant protocol synchronization using ACK messages are also required. These would require all ground stations to be capable and licensed to transmit, which is not always the case, as some ground stations are “receive only” for logistical or legal reasons.
As a further example, RDP requires that the ground station and satellite maintain a shared state in which they are synchronized, via handshakes and/or acknowledgements. Should either the ground or satellite side fail to transmit “ACK” and/or the other side fail to receive the “ACK,” no data transmission can occur until a timeout occurs.
As a further example, in certain situation, both nodes may need to terminate a communication or essentially “sign off” and hear the other side sign off. If one node does not hear the other node “sign off,” then it would continue to be stuck in transmission. Such a shared state can occur, for example, in the maintenance of sequence numbers. However, the shared state is impracticable in a half-duplex system where only one node can transmit at one time. A need exists for improved systems and methods to address such issues and challenges.